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INTRODUCTION 

The purpose of this overview is to provide information on how to 
use the Information System Life-Cycle and Documentation 
Standards, (commonly referred to as the Standards) . This 
information will cover description, objectives, key definitions, 
structure and application of the Standards, and document 
structure decisions. 

DESCRIPTION 

The Standards have been created by the Software Management and 
Assurance Program (SMAP) to provide consistent NASA-wide 
structures for documenting information systems and their 
components. It is the responsibility of the appropriate 
program/project manager to enforce the use of the SMAP Standards 
and to ensure their use is integrated with other standards 
available at the NASA centers. 

The Standards document consists of five SMAP Standards: 

- The Information System Life-Cycle Standard 

- The Management Plan Documentation Standard 

- The Product Specification Documentation Standard 
The Assurance Specification Documentation Standard 

The Management Control and Status Reports Documentation 
Standard. 

The last four items listed above are collectively referred to as 
the ” Documentation Standards.” Therefore, the entire book has 
been titled: 

"Information System Life-Cycle and Documentation Standards.” 
OBJECTIVES 

The purpose of the SMAP Standards is to provide a standard, 
tailorable life-cycle process, and the structure and formats for 
documenting products of that process. The Standards are 
applicable to information systems and their software, hardware, 
and operational procedures components. The Standards address 
only life-cycle and documentation structures; not specific 
management, engineering, technical, or assurance standards and 
practices. As such, they complement and augment other existing,, 
standards, such as detailed hardware engineering and assurance 
standards used at various NASA centers. The Standards have been 
written to be methodology independent for general applicability. 
For example, they are flexible enough to be applied to either 
object-oriented or structured software design methodologies. 
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DEFINITIONS 


A first step in ensuring consistency is to make sure all readers 
are speaking the same language. Therefore, one must first become 
familiar with the terminology of the Standards. 

An INFORMATION SYSTEM is any system composed of hardware, 
software, and operational procedures components required to 
process, store, and transmit data. Information Systems, 
within the context of these Standards are software-intensive 
systems. Conversely, the act of separating an information 
system into its hardware, software, and operational 
procedures components (or into subsystems) is called SYSTEM 
DECOMPOSITION. 

^he terms hardware and software should be familiar to users 
of the Standards and will not be defined here. However, the 
term OPERATIONAL PROCEDURES may be open to interpretation 
and, therefore, is defined in the Standards as the manual 
procedures or processes (conducted by the operator of the 
system) that are an integral part of an information system's 
operational capability provided to end users. Within the 
above definition, then, an OPERATOR (one who executes the 
operational procedures) , is internal to the information 
system, while a USER is external to the system. Operators 
executing the operational procedures work in conjunction 
with the hardware and software to provide the operational 
capabilities of the information system to the user. 

An example of this distinction can be seen in a word 
processing system that employs a spell checker. A 
system design decision would be whether to have the 
spell checker available to the user immediately upon 
request by having it a part of the main program, or 
whether to have it on a floppy disk, which must be 
loaded manually into the disk drive each time it is 
needed. Assuming the later choice was made, the act of 
loading the spell checker floppy would be an 
operational procedure performed by an operator. The 
act of spell checking the document would be performed 
by the user. It can be seen that the distinction is 
sometimes a fine line; and, in this example, the 
operator and user functions probably would be performed 
by the same person. 

The organization obtaining a capability (i.e., a product 
such as an information system or a service such as quality- 
assurance) is called the ACQUIRER, The organization 
supplying the capability to an acquirer is called the 
PROVIDER. 
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Any information system (or its hardware, software, or 
operational procedure component) will require four distinct 
types of documentation. These are: 

A Management Plan document 

- A Product Specification document 
An Assurance Specification document 

- A Management Control and Status Reports document. 

These four documents are referred to in the Standards as a 
DOCUMENTATION SET. For relatively small projects, there 
will be literally only four documents required for the 
management, development, assurance, and feedback reporting 
for the product and associated processes. 

For large projects, some sections of the four documents in 
the Documentation Set will be so large, or will have to be 
written by different providers in different locations, to 
necessitate placing them in separate volumes. The 
Documentation Standards provide a mechanism called the ROLL- 
OUT concept for recording sections of a document in 
physically separate volumes while maintaining traceability 
and links back to the original document. A volume can be 
rolled-out from a document or from another volume (i.e., 
volumes can be subsets of documents, or subsets of other 
volumes) . In either case, the document or volume from which 
another volume is ROLLED-OUT is referred to as the PARENT 
(document or volume) . 

Within the Documentation Standards, a DATA ITEM DESCRIPTION 
(DID) provides a blueprint from which a writer can create 
one of the four documents in the Documentation Set, or any 
volume that is to be rolled-out from a document or other 
volume. 

To ensure that all volumes created from the DIDs follow the 
same structured format making them consistent with one 
another, the Standards provide a tool called a TEMPLATE. 

The TEMPLATE provides a common place for sections of 
documentation that are common to all DIDs. These common 
sections occur at the beginning and end of the DIDs. (The 
content in the middle of the DID is what distinguishes one 
DID from another.) Examples of common sections include: 

Introduction 

Related Documentation 

Abbreviations and Acronyms 

Glossary 

Notes 

Appendices 
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A tailoring mechanism, which can be used for small projects, 
is called the IN-LINE concept, (It is the opposite of the 
Roll-Out concept.) Using the In-Line concept, a writer can 
incorporate the contents of several lower level DIDs into a 
single document. 

STRUCTURE OF THE STANDARDS 

The Standards themselves have been written using the in-line and 
the roll-out concepts. The parent document titled Information 
System Life-Cycle and Documentation Standards contains the Life- 
Cycle Standard in-line, while the four Documentation Standards 
have been rolled-out into separate volumes. For convenience of 
use, the Standards have been packaged as five separate small 
books . 

Each of the four Documentation Standards contains a set of DIDs 
and the necessary structural guidance on how to use them. 
Additionally, each Documentation Standard contains sample 
outlines as appendices which should further help introduce the 
user to the structure of documents written to the Standards. 

APPLICATION 

This section will describe how to use the Information System 
Life-Cycle and Documentation Standards to create documents for a 
NASA project. 

Using the Life-Cvcle Standard 

For information specifically concerning the life-cycle, the 
parent document, the Life-Cycle Standard should be used. It 
contains a separate section for each of the life-cycles: 
information system, hardware, software, and operational 
procedures. It also contains direction for when in the 
life-cycle the sections of documents in the Documentation 
Set should be written, updated, or reviewed. It also 
defines the activities of management, engineering, and 
assurance organizations during each phase of the life-cycle. 
Finally, it contains information on how to tailor the 
standard life-cycle to the nuances of a particular project. 
For example, guidance is given for employing evolutionary 
acquisition, phased delivery, incremental development, and 
prototyping techniques. 
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Using the Documentation Standards - A Sample 


The Documentation Standards are tailorable to the project 
application size, from a single physical volume to a multi- 
volume set for each document type. For information 
concerning the preparation of a specific document in the 
Documentation Set, one would refer to the volume of the 
Standards for the type of document being created. (In the 
following discussion, assume that the Product Specification 
Documentation Standard and DIDs volume will be used to 
create a Software Product Specification.) 

After reading the concept, rule, and guideline information 
in Sections 1 through 6 of the volume, one would begin by 
turning to the Software Product Specification Sample 
Outline, (provided in the Standard as Appendix C) , for an 
overview of the document. Next, one would go to the highest 
level DID available — in this case, the Software Product 
Specification DID. Lower level DIDs will be used when more 
detail and substructure is required. 

DID Substructure - The DID Numbering System 

To help the user implement DID substructure, the Standards 
provide an alphanumeric numbering system. Within this 
system, the first letter is always either M, P, A, or R (M 
for management plan, P for product specification, A for 
assurance specification, and R for report) . The next three 
numeric digits indicate substructure. A zero in all three 
digits represents the highest level document possible (i.e. 
one of the four documents in the Documentation Set: 
Management Plan, Product Specification, Assurance 
Specification, or Management Control and Status Reports) . 
Subsequent levels of substructure are shown by first the 
hundreds digit, next the tens digit, and finally the units 
digit. 

A two-letter suffix is added when the DID applies only to an 
information system or component. A DID that applies solely 
to an information system is identified by "-SY" . A DID that 
applies equally well to hardware, software, or operational 
procedures components is identified by "-C0" . Where the DID 
applies to only one type of component, "-HW" is used for 
hardware, "-SW" for software, and "-0P" for operational 
procedures. The absence of a suffix indicates that the DID 
can apply "across the board" to information systems, 
hardware, software, or operational procedures. 
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Table 1 shows how the DIDs are applied in a structured 
manner to a Software Product Specification. POOO-SW is the 
highest level DID. P100, P200-SW, P400, P500, and P600-SW 
are subsets of POOO-SW. Note that the system is not 
completely sequential. On Table 1, there is no P300 because 
P300-SY is solely for an information system and Table 1 
applies to a software product specification. P310-SW and 
P320-SW perform the equivalent function of P300-SY for the 
software component. Continuing, P210 is a subset of P200- 
SW, and P311-SW is a subset of P310-SW. Finally, P321-SW 
and P322-SW are subsets of P320-SW. To summarize the logic 
behind the DID numbering system, hundreds digits are 
subordinate to triple zeroes, tens digits are subordinate to 
hundreds digits, and units digits are subordinate to tens 
digits. For further clarity, indentation is used to show 
levels of substructure. 

When DID substructure is desired, the Standards use the 
roll-out and in-line concepts, along with the template as 
tailoring devices. Figure 1 shows a graphic example of how 
DIDs and the template are applied when a document is rolled- 
out into lower level volumes. Figure 2 shows a contrasting 
example of how a document is created using the substructure 
from the more detailed DIDs in-line, incorporating them into 
a higher level document. 

Structure Decisions 

It is the responsibility of the manager to define the life- 
cycle adaptation for the information system or component 
based on the SMAP Life-Cycle Standard. The manager must 
decide whether the information system is complex enough to 
require system decomposition into subsystems and/or 
components. If so, it must be determined whether each 
element of decomposition should have its own life-cycle and 
associated Documentation Set. 

The manager also defines the type and amount of information 
to be placed in each of the four documents of the 
Documentation Set. For each section of each document, the 
manager decides whether: (1) whether information is placed 
in-line in that section (2) whether the section is marked 
"not applicable" (3) whether the information for that 
section is rolled-out into a physically separate volume. As 
each document may consist of one or more volumes, the 
manager defines the number of volumes to be produced for 
each document by section roll-out decisions. 
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TABLE 1 


COMPLETE DID SET FOR A SOFTWARE PRODUCT SPECIFICATION 


SMAP— DID— P000— SW Software Product Specification DID 
SMAP-DID-P100 Concept DID 

SMAP-DID-P2 OO-SW Software Requirements DID 

SMAP-DID-P210 External Interface Requirements DID 

SMAP-DID-P3 10-SW Software Architectural Design DID 

SMAP-DID-P3 11-SW Software External Interface Design 


DID 

SMAP-DID-P320-SW Software Detailed Design DID 

SMAP-DID-P3 2 1-SW Software External Interface 

Detailed Design DID 

SMAP-DID-P3 2 2 -SW (Software) Firmware Support Manual 

DID 

SMAP-DID-P4 00 Version Description DID 

SMAP-DID-P500 User's Guide DID 

SMAP-DID-P6 00-SW Software Maintenance Manual DID 
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FIGURE 1 


Roll-Out Example. 
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FIGURE 2 


Incorporating DID Substructure In-Line. 


PRODUCT SPECIFICATION DOCUMENTATION STANDARD 





Information 
System Life Cycle 


Information 
System Life Cycle 


INFORMATION SYSTEM 
CONCEPT AND 
INITIATION PHASE 


INFORMATION SYSTEM 
INTEGRATION AND 
TEST PHASE 




SOFTWARE CONCEPT AND 
INITIATION PHASE 


PRODUCTS 


- Component Management Plan 
(Preliminary) 

- Component Acquisition Plan 

- Request for Proposal (RFP) 

- Work Breakdown Structure 
(WBS) 

- Software Development Con- 
tract (Note 1) 

- Configuration Management 
Plan (Initial) 

- Risk Management Plan 

- Assurance Plan (Initial) 

(Note 2) 

- Software Product Specification 
(Preliminary) 

- Concept Document ! 

- Software Requirements Specifi- 
cation (Initial) 

- Assurance Specification 
(Preliminary) (Note 2) 

- Lessons-Learned Document 

- Assurance Report(s) (Note 2) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA - Prepare Inputs to System 
EA Specification 
MA - Prepare Component Manage- 
ment Plan 

MA - Prepare Component Acquisi- 
tion Plan 

MA - Prepare RFP 
MA - Prepare Assurance Plan 
MA - Review Appropriate Lessons- 
EA Learned 

MA - Review Proposals and Select 

EA Contractor 

MA - Negotiate and Award 


EA 

MA 

EA 

EA 


EA 

AA 

AA 

AA 

AA 


Contract 

- Revise Component Manage- 
ment Plan 

- Review and Approve Concept 
Document 

- Review and Approve Software 
Requirements Specification 
(Initial) 

- Schedule and Prepare for 
Concept Review 

- Prepare Assurance Report(s) 

- Prepare Concept Review 
Report 

- Prepare Lessons-Learned 
Report 


POTENTIAL CONTRACTOR 
(PROVIDER) ACTIONS 


MA - Review NASA Component 
EA Acquisition RFP 
MA - Prepare and Submit 
EA Proposal 


CONTRACTOR (PROVIDER) 
ACTIONS 


MA - Negotiate Contract 
EA 

- Prepare and Submit Concept 
Document 

- Prepare and Submit Software 
Requirements Specification 
(Preliminary) 

- Prepare for Concept Review 

- Prepare Assurance Report(s) 

- Prepare Lessons-Learned 
Report 


EA 


EA 


EA 

AA 

AA 


PHASE TRANSITION REVIEW: 


NASA Software Management Baseline 



INFORMATION SYSTEM 
LIFE CYCLE AND 
DOCUMENTATION STANDARDS 
(RELEASE 4.3) 

INDEX CODES 

M — Management Plan Documentation 
Standard Volume contains DID for 
this documentation product 
P — Product Specifications Documen- 
tation Standard Volume contains 
DID for this documentation product 
A — Assurance Specifications Documen- 
tation Standard Volume contains 
DID for this documentation product 
R — Management Control & Status 

Reports Documentation Standard 
Volume contains DID for this 
documentation product 


OTHER INDEX CODES 

PI — Software Product 
MA — Management Activity 
EA — Engineering Activity 
AA — Assurance Activity 


Version 4.0 
1989 


SOFTWARE 

REQUIREMENTS PHASE 


PRODUCTS 


- Component Development Plan 

- Configuration Management 
Plan (Final) 

- Assurance Plan (Update) 

(Note 2) 

- Test Plan (Initial) (Note 3) 

- (Independent) V&V Plan (Initial) 

- Sustaining Engineering and 
Operations Plan (Preliminary) 

- Software Requirements Specifi- 
cation (Final) 

- External Interface Require- 
ments Document 

- User's Guide (Preliminary) 

- Acceptance Test Document 
(Initial) (Note 3) 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 
(ECP) 

- Lessons-Learned Document 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA 

EA 


- Review and Approve Compo- 
nent Development Plan 


MA - Review Lessons- 
EA Learned 
MA - Review Test Plan 
EA (Initial) 

MA - Review (I) V&V Plan 
EA (Initial) 

MA - Review and Approve S.E. and 
EA Operations Plan (Preliminary) 
MA - Review and Approve Software 
EA Requirements Specification 
(Final) 

MA - Review and Approve External 
EA Interface Requirements 
Document (Update) 

EA - Review and Approve User's 
Guide (Preliminary) 

AA - Review Acceptance Test 
Document (Initial) 

AA - Review and Approve Dis- 
crepancy (NRCA) Reports 
AA - Review and Approve ECP(s) 
AA - Review and Approve Lessons- 
Learned Document 
AA - Review and Approve Assur- 
ance Report(s) 

AA - Schedule and Prepare for 
Phase Transition Reviews 
AA - Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


MA - Prepare and Submit Compo- 
EA nent Development Plan 
MA - Prepare and Submit Config- 
EA uration Management Plan 
(Final) 

- Prepare and Submit Plans 

- Prepare and Submit Software 
Requirements Specification 
(Final) 

MA - Prepare and Submit Interface 
Requirements Document 
(Update) 

- Prepare and Submit User's 
Guide (Preliminary) 

- Prepare and Submit Items 
from Previous Phase 

- Prepare and Submit Phase 
Transition Review Report(s) 

- Prepare and Submit Other 
Reports 


EA 

MA 

EA 


EA 


EA 


EA 


AA 


AA 



PHASE TRANSITION REVIEW: 


Software Requirements 
Review (SRR) 


Software Requirements Baseline 


SOFTWARE 
ARCHITECTURAL 
DESIGN PHASE 


PRODUCTS 


M - Assurance Plan (Final) (Note 2) 
M - Test Plan (Final) (Note 3) 

M - I (V&V) Plan (Final) 

M - Engineering and Integration 
Plan (Initial) 

M - Product Support Plan (Note 4) 

P - Software Architectural Design 
Specification 

A - Acceptance Test Document 
(Update) (Note 3) 

A - Integration Test Document 
(Initial) (Note 3) 

R - Prototyping (Performance/ 
Status) Report 

R - Discrepancy (NRCA) Reports 
R - Engineering Change Proposal(s) 
(ECP) 

R - Lessons-Learned Document 
R - Assurance Report(s) 

R - Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 


® 


NASA 

National Aeronautics and 
Space Administration 


MA - Review Lessons- 
EA Learned 
MA - Review and Approve 
EA Plans 

EA - Review and Approve Soft- 
ware Architectural Design 
Specification 

AA - Review and Approve Accept- 
ance Test Document (Update) 
AA - Review and Approve Integra- 
tion Test Document (Initial) 
AA - Review and Approve Proto- 
typing (Performance/Status) 

Report 

AA - Review and Approve Dis- 
crepancy (NRCA) Reports 
AA - Review and Approve ECP(s) 
AA - Review and Approve Lessons- 
Learned Document 
AA - Review and Approve Assur- 
ance Report(s) 

AA - Schedule and Prepare for 
Phase Transition Reviews 
AA - Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


ME 

AA 

EA 


EA 

AA 

EA 

AA 

EA 

AA 

EA 

AA 

AA 


- Prepare and Submit 
Plans 

- Prepare and Submit Software 
Architectural Design Specifi- 
cation 

- Prepare and Submit Accept- 
ance Test Document (Update) 

- Prepare-and Submit Integra- 
tion Test Document (Initial) 

- Prepare and Submit Proto- 
typing (Performance/Status) 
Report 

- Prepare and Submit Items 
from Prior Phase 

- Prepare and Submit Phase 
Transition Review Reports 

- Prepare and Submit Other 
Reports 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 



PHASE TRANSITION REVIEW: 


Software Preliminary 
(Architectural) Design 
Review (PDR) 





Software Allocated Baseline 


SOFTWARE DETAILED 
DESIGN PHASE 


PRODUCTS 


M 


- Engineering and Integration 
Plan (Update) 

- Software Detailed Design 
Specification 

- Acceptance Test Document 
(Update) (Note 3) 

- Integration Test Document 
(Update) (Note 3) 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 

- Lessons-Learned Document 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA - Review Lessons- 
EA Learned 
MA - 

EA gration Plan (Update) 

EA - Review and Approve Software 
Detailed Design Specification 
AA - Review and Approve Accept- 
ance Test Document (Update) 
AA - Review and Approve Dis- 
crepancy (NRCA) Reports 
AA - Review and Approve Engi- 
neering Change Proposal(s) 

AA - Review and Approve Lessons- 
Learned Document 
AA - Review and Approve Assur- 
ance Report(s) 

AA - Schedule and Prepare for 
Phase Transition Reviews 
AA - Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


MA - Prepare and Submit Engi- 
EA neering and Integration Plan 
(Update) 

EA - Prepare and Submit Software 
Detailed Design Specification 
EA - Prepare and Submit Accept- 
ance Test Document 
AA - Prepare and Submit Dis- 
crepancy (NRCA) Reports 
AA - Prepare and Submit Engi- 
neering Change Proposal(s) 
AA - Prepare and Submit Lessons- 
Learned Document 
AA - Prepare and Submit Assur- 
ance Report(s) 

AA - Prepare for Phase Transition 
Reviews 

AA - Prepare and Submit Items 
from Prior Phase 
AA - Prepare and Submit Phase 
Transition Review Report(s) 
AA - Prepare and Submit Other 
Reports 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 



PHASE TRANSITION REVIEW: 


Software Critical 
Design Review (CDR) 




Software Design Baseline 


I 


PROTOTYPING 

! PRODUCTS: 

Prototype Planning Document 
Revisions to Management Plans 

Revised Prototype Planning 
Document 

Revisions to Management Plans 

Engineering Change Proposal(s) 
Prototype Code and Data 

! NASA ACTIONS: 

Identify Prototype Objectives and 
Approve Items to be Prototyped 

Review and Approve Prototype 
Planning Document 

Review and Approve Engineering 
Change Proposals 

Monitor Prototyping Activities and | 

Provide Technical Direction 

Review Design and Construction 
Staff Reports 

Assess Utility of Prototype Code and 
Data 

L 

Monitor Prototyping Activities and 
Provide Technical Direction 


! CONTRACTOR ACTIONS 

Prepare Prototype Planning 
Document 

Prepare Engineering Change 
Requests 

Prepare Revisions to Development 
Plans 

Perform Approved Prototyping 
Activities 

Develop and Test Prototype Code 
and Data 

Prepare Design and Development 
Staff Reports 


SOFTWARE 

IMPLEMENTATION 

PHASE 


PRODUCTS 


M - Engineering and Integrgtion 
Plan (Final) 

PI - Software Component (Pretest) 

P - User's Guide (Update) 

P - Software Maintenance Manual 
A - Acceptance Test Docunent 
(Update) (Note 3) 

A - Integration Test Document 
(Update) (Note 3) 

- Unit Test Document (Note 3) 

- Unit Test Report 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 

- Lessons-Learned Docunent 

- Customer Inspection Report 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA - Review Lessons- 
EA Learned 

EA - Review Software Component 
(Pretest) 

EA - Review User's Guide (Update) 
EA - Review and Approve Soft- 
ware Maintenance Manual 
AA - Review Acceptance Test 
Document (Update) 

AA - Review Integration Test 
Document (Update) 

AA - Review and Approve Unit 
Test Document 
AA - Review Unit Test Report 
AA - Review and Approve Dis- 
crepancy (NRCA) Reports 
AA - Review and Approve Engi- 
neering Change Proposal(s) 
AA - Review and Approve Lessons- 
Learned Document 
AA - Review and Approve Assur- 
ance Report(s) 

AA - Schedule and Prepare for 
Phase Transition Revisw 
AA - Review and Approve °hase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


EA - Prepare Software Component 
(Pretest) 

EA - Perform Lower Level Soft- 
ware Coordination Activities 
EA - Prepare and Submit User's 
Guide (Update) 

EA - Prepare and Submit Soft- 
ware Maintenance Manual 
AA - Prepare and Submit Accept- 
ance Test Document (Update) 
AA - Prepare and Submit Integra- 
tion Test Document (Update) 
AA - Prepare and Submit Unit 

Test Document and Feport 
EA - Prepare and Submit liems 
AA from Previous Phase 
AA - Prepare and Submit Phase 
Transition Review Report(s) 
AA - Prepare and Submit Other 
Reports 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 



PHASE TRANSITION REVIEW: 


Functional Configuration 
Audit (FCA) 

Software Peer Reviews, 
Walkthroughs 



Software Code Baseline 



SOFTWARE 
INTEGRATION AND 
TEST PHASE 


PRODUCTS 


M 


M 


PI 


- Component Management Plan 
(Final) 

- Sustaining Engineering and 
Operations Plan (Final) 

- Software Component (Post- 
Integration Test) 

- Version Description Document 
(VDD) (Initial) 

- User’s Guide (Update) 

- Acceptance Test Document 
(Update) (Note 3) 

- Integration Test Document 
(Final) (Note 3) 

- Integration Test Report 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 
(ECP) 

- Lessons-Learned Document 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA 

EA 

MA 

EA 


EA 

EA 

AA 

EA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 


- Review Lessons- 
Learned 

- Prepare Management Plan 
(Final) 

- Review and Accept Sustain- 
ing Engineering and Opera- 
tions Plan (Final) 

- Review Software Component 
(Post-Integration Test) 

- Review VDD 
(initial) 

- Review User's Guide (Update) 

- Review Acceptance Test 
Document (Update) 

- Review and Approve Integra- 
tion Test Document (Final) 

- Review and Approve Integra- 
tion Test Report 

- Review and Approve Dis- 
crepancy (NRCA) Reports 

- Review and Approve ECP(s) 

- Review and Approve Lessons- 
Learned Document 

- Review and Approve Assur- 
ance Report(s) 

- Schedule and Prepare for 
Phase Transition Reviews 

- Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


EA 


EA 


EA 

AA 

EA 

AA 

AA 

AA 

EA 

AA 

AA 

AA 


- Prepare and Submit Sustain- 
ing Engineering and Oper- 
ations Plan (Final) 

- Prepare and Submit Software 
Component (Post-Integration 
Test) 

- Prepare and Submit 
VDD (Initial) 

- Prepare and Submit User's 
Guide (Update) 

- Prepare and Submit Accept- 
ance Test Document (Update) 

- Prepare and Submit Integra- 
tion Test Document (Final) 

- Prepare and Submit Integra- 
tion Test Report 

- Prepare and Submit Items 
from Previous Phase 

- Prepare and Submit Phase 
Transition Review Reports 

- Prepare and Submit Other 
Reports 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 


PHASE TRANSITION REVIEW: 


Software Test Readiness 
Review (TRR) 


Software Integrated 


Product Baseline 


SOFTWARE 
ACCEPTANCE AND 
DELIVERY PHASE 


PRODUCTS 


PI - Software Component (Post- 
Acceptance Test) 

P - Software Product Specification 
(Final) 

P - Version Description Document 
(VDD) (Final) 

P - User's Guide (Final) 

A - Assurance Specification 
(Final) (Notes 2, 3) 

A - Acceptance Test Document 
(Final) (Note 3) 

- Certification Report 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 
(ECP) 

- Lessons-Learned Document 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA 

EA 

EA 

EA 


EA 

EA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 

AA 


- Review Lessons- 
Learned 

- Review Software Component 
(Post-Acceptance Test) 

- Review and Approve Soft- 
ware Product Specification 
(Final) 

- Review and Approve VDD 
(Final) 

- Review and Approve User's 
Guide (Final) 

- Review and Approve Assur- 
ance Specification (Final) 

- Review and Approve Accept- 
ance Test Document (Final) 

- Review and Approve Certifi- 
cation Report 

- Review and Approve Dis- 
crepancy (NRCA) Reports 

- Review and Approve ECP(s) 

- Review and Approve Lessons- 
Learned Document 

- Review and Approve Assur- 
ance Report(s) 

- Schedule and Prepare for 
Phase Transition Reviews 

- Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


EA 


EA 

EA 

EA 

AA 

AA 

AA 

EA 

AA 

AA 

AA 


- Prepare and Submit Software 
Component (Post-Acceptance 
Test) 

- Prepare and Submit Software 
Product Specification (Final) 

- Prepare and Submit VDD 
(Final) 

- Prepare and Submit User's 
Guide (Final) 

- Prepare and Submit Assur- 
ance Specification (Final) 

- Prepare and Submit Accept- 
ance Test Document (Final) 

- Prepare and Submit Certifica- 
tion Report 

- Prepare and Submit Items 
from Previous Phase 

- Prepare and Submit Phase 
Transition Review Report(s) 

- Prepare and Submit Other 
Reports 


PHASE TRANSITION REVIEW: 


Software Acceptance Review 

Functional Configuration 
Audit (FCA) 

Physical Configuration 
Audit (PCA) 


SOFTWARE SUSTAINING 
ENGINEERING AND 
OPERATIONS PHASE 


PRODUCTS 


- Revised Component Manage- 
ment Plan 

- Modified/Enhanced Software 
Component 

- Revised Product Specification 

- Revised Requirements and 
Design Documents 

- Revised Version Description 
Document (VDD) 

- Revised User's Guide 

- Revised Assurance Specification 

- Revised Acceptance Test 
Document (Note 3) 

- Acceptance Test Report 

- Discrepancy (NRCA) Reports 

- Engineering Change Proposal(s) 

- Lessons-Learned Document 

- Assurance Report(s) 

- Phase Transition Review 
Report(s) 


NASA (ACQUIRER) 
ACTIONS 


MA - Review Lessons-Learned 
Document 
MA - Update Plans 
EA - Review/Approve Revised 
AA Product Specifications 
EA - Review/Approve Revised 
AA * Requirements, Design, VDD 
EA - Review/Approve Revised 
AA User's Guide 
EA - Review/Approve 
AA Reports 

AA - Schedule and Prepare for 
Phase Transition Reviews 
AA - Review and Approve Phase 
Transition Review Report(s) 


CONTRACTOR (PROVIDER) 
ACTIONS 


EA - Review Lessons-Learned 
Documents 

EA - Revise/Modify Requirements 
and Design Specifications 
EA - Implement Approved Engi- 
neering Proposals 
EA - Test Modified/Enhanced 
AA Software Component 
EA - Prepare and Submit Items 
AA from Previous Phase 
EA - Revise/Modify 
AA Documents 
AA - Prepare and Submit Phase 
Transition Review Report(s) 
AA - Prepare and Submit Other 
Reports 


Software Accepted (As Built) Baseline 


Security and Privacy 
Assurance 
(Independent) V&V 
Certification 


NOTE 1 — The Contract, negotiated between NASA project management and 
contractor, is on the chart for completeness. It is not a DID product. 

NOTE 2 — Assurance is rolled out to a more detailed level using the follow- 
ing DIDs: 

Quality Assurance 
Testing 

Quality Engineering Assurance 
Safety Assurance 

NOTE 3 — Test documents (or subsections), not shown in detail on the chart, 
have, at a minimum, the following primary topics: 

Test ID and Specifications Actual Results (documented 

Test Criteria in the appropriate manage- 

Test Procedures ment control and status 

Test Cases and Expected reports section) 

Results 

NOTE 4 — This item is identified in the Sustaining Engineering and Opera- 
tions Plan DID. 


PRODUCTS, ACTIONS, AND PHASE TRANSITION 
REVIEWS THAT WOULD EXEMPLIFY A TYPICAL 
LARGE SCALE SOFTWARE PROJECT 


OFFICE OF SAFETY, RELIABILITY, 
MAINTAINABILITY AND QUALITY ASSURANCE 

NASA SOFTWARE MANAGEMENT AND 
ASSURANCE PROGRAM (SMAP) 


APPROVED BY. 





MR. GEORGE A. RODNEY, ASSOCIATE ADMINISTF VTOR 



* Prototyping is defined within the scope of the standard as a process 
(or method) used within the life-cycle to assess and/or reduce risk or 
to gain knowledge. Although usually used within a phase, it is shown, 
for the example here, as extending over several phases. 


REWORK ACTIVITIES 
OVERLAP ACTIVITIES 


APPROVED BY. 


MR. DONALD 


/kfy^dX.. pi . 

W. SOVA, MANAGER, SMAP V 


